home *** CD-ROM | disk | FTP | other *** search
/ Amiga Developer CD 2.1 / Amiga Developer CD v2.1.iso / Reference / Amiga_Mail_Vol2 / Archives / Plain / ja91 / ASCII / SubmitIFF / SubmitIFF.txt
Encoding:
Text File  |  1991-08-09  |  5.9 KB  |  117 lines

  1. (c)  Copyright 1991 Commodore-Amiga, Inc.   All rights reserved.
  2. The information contained herein is subject to change without notice,
  3. and is provided "as is" without warranty of any kind, either expressed
  4. or implied.  The entire risk as to the use of this information is
  5. assumed by the user.
  6.  
  7.  
  8. Developing New IFF FORMs and Chunks
  9.  
  10. by Christian Ludwig - Multimedia Standards Engineer, CATS
  11.  
  12.  
  13.  
  14. IFF has been one of the keys to the Amiga's superiority in multimedia
  15. applications, allowing interchange of media elements between packages.  The
  16. wealth of standard IFF FORMs and chunks gives the Amiga user data-sharing
  17. capabilities that are virtually unequaled on other systems.  The Amiga's
  18. ability to render an image, touch it up, convert it to a different display
  19. mode, and load it into in another package is something that is a chore on
  20. other platforms, simply because the format of the image file may be different
  21. from one application to the next.  IFF files lessen the need for
  22. ``conversion'' software, because most Amiga applications can read and write
  23. them.
  24.  
  25. Since its introduction as an open standard in 1985, IFF has widened to
  26. encompass data of many sorts--and the need for new IFF types continues to
  27. grow.  To satisfy these growing needs, developers will continue to define and
  28. support new IFF types.  Now that both the console and iffparse.library
  29. support sharing IFF files through the clipboard in release 2.0, IFF support
  30. is more important than ever.
  31.  
  32. When developing a new IFF type, there are several steps you should follow:
  33.  
  34. o Discuss needs and specifications within the developer community and with
  35. Commodore.
  36.  
  37. The most important thing about designing IFF FORMs and chunks is that they
  38. meet the data storage and transfer needs of multiple applications.  When more
  39. than one product uses the same IFF type, the market widens for all products
  40. that use that IFF type.  Users are not forced to use one product or another,
  41. but can buy as many as they need to get the job done, fully utilizing all the
  42. features that each product has to offer.  This step helps to ensure that a
  43. proposed IFF form or chunk type is flexible and isn't redundant.  A good way
  44. to start this kind of discussion is to post a message in Commodore's
  45. amiga.dev/iff conference on the BIX electronic network.  Also, feel free to
  46. contact me to discuss your IFF needs and issues.  You can reach me at (215)
  47. 431-9316 or on BIX (cludwig).  I can also be reached via UseNet InterNet
  48. e-mail at:
  49.  
  50.         chrisl@cbmvax.commodore.com or ...[uunet|rutgers]!cbmvax!chrisl.
  51.  
  52.  
  53. o Implement the new type and conduct feasibility tests.
  54.  
  55. Before settling on a format, set up prototype code to test the proposed
  56. format.  This will help to prove that the idea is sound and can be
  57. implemented in software before others try to use it.
  58.  
  59.  
  60. o Submit specifications to Commodore.
  61.  
  62. Coming up with a new kind of IFF FORM or chunk is easy--almost too easy.
  63. Just about anyone can follow the IFF guidelines and define their own FORM or
  64. chunk.  If every application used a different IFF FORM, one application would
  65. be unable to share data with another because it can't read the other
  66. application's IFF FORM1.  It's like making up a new word for something that
  67. everyone sees every day.  You may understand what the word means, but when
  68. you try to use your new word to communicate with others, they won't
  69. understand you.  Further, deciding to use a pre-existing FORM or chunk in a
  70. new and different way is a lot like making up your own meaning for a
  71. pre-existing word.  Confusion results when programs try to read FORMs or
  72. chunks whose meaning was altered by a non-conforming program.
  73.  
  74. To avoid the problem of incompatible IFF types, register your new IFF types
  75. with CATS.  CATS acts as a ``dictionary'' of IFF types.  By submitting your
  76. proposals for FORM or chunk types to CATS, you help prevent duplication of an
  77. existing data type.  Also, if you register your new IFF type, it is more
  78. likely that it will be adopted as an IFF standard that other applications
  79. will use.  For example, the ANIM form came from third party developers who
  80. proposed and refined the format.  Now ANIM is the de facto standard for
  81. animation files.
  82.  
  83. CATS wants this last step to be as easy as possible, so we've included a
  84. standard form at the end of this article.  Just photocopy the form whenever
  85. you need it, and use it as a guide for submitting your FORM or chunk
  86. specifications.  The registration form should be
  87.  
  88. accompanied by a disk containing ASCII text files of the IFF specification.
  89. If available, include some code examples which demonstrate the use of the IFF
  90. type.  Please do not place copyright notices in your specifications or
  91. examples so that CATS may make them available to other developers.
  92.  
  93. For an excellent example of a third party FORM specification, see the WORD
  94. FORM in the third party specification section of the IFF manual.   For an
  95. example of chunk descriptions, examine the 8SVX FORM's SEQN and FADE chunks
  96. in the same section.
  97.  
  98. Note that even you don't plan to release the specifications of your FORM or
  99. chunk, you must still register the name with CATS.  This is the only way to
  100. prevent name conflicts in IFF files.  You should register your FORM and chunk
  101. names before finalizing your product and its documentation in case there is a
  102. name conflict with an existing IFF type.
  103.  
  104.  
  105. o Distribute final specifications to the developer community.
  106.  
  107. Once you have registered your FORM or chunk with CATS, you should release the
  108. specifications of the chunk to the developer community.  Although CATS
  109. publishes FORMs and chunks in the IFF Manual and occasionally in Amiga Mail,
  110. developers should not rely on these methods to distribute their IFF type
  111. specification.  One of the most efficient ways to distribute your
  112. specification is to include it in your application's documentation.  Another
  113. good distribution method is to post the final specifications in amiga.dev/iff
  114. on BIX.  Distributing the specification will increase the probability of your
  115. form or chunk becoming a standard.
  116.  
  117.